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Report  on  Senior  Executive  Seminars  on  Software 

issues 

Abstract:  This  report  expands  on  the  activities  executed  by  the  Software 
Engineering  Institute  (SEI)  associated  with  raising  the  software  issue  awareness 
of  senior  executives  in  the  three  principal  constituent  areas  of  the  SEI:  senior 
defense  officials,  industry  executives,  and  senior  academic  personnel.  In  planning 
for  and  executing  these  activities,  the  SEI  has  responded  to  one  of  the  principal 
aspects  of  its  charter,  which  is  to  address  the  most  important  software-related 
issues  applicable  to  the  Department  of  Defense  (DoD)  and  the  software  industry 
in  the  United  States. 

1  Initial  Actions 

In  1 988,  the  SEI  decided  to  provide  a  forum  in  which  major  software  issues  could  be 
addressed.  Thus,  a  workshop  was  held  during  the  last  quarter  of  calendar  year  1 988. 
The  Workshop  on  Executive  Software  Issues  was  held  in  two  parts:  August  2-3  and 
November  18, 1988.  A  full  discussion  of  these  software  issues  resulted  in  SEI  Technical 
Report.  CMU/SEI-89-TR-6.  published  in  January  1989.  The  topics  addressed  at  this 
workshop  centered  on  three  major  categories:  national  strategy,  acquisition,  and  building 
large  complex  systems.  The  identified  issues  and  recommendations  were  extensive  in 
their  scope  and  underlined  the  fact  that  there  was  no  foaim  or  mechanism  through  which 
such  issues  could  be  developed  further  and.  ultimately,  addressed  within  the  DoD.  The 
technical  report,  however,  did  serve  as  a  record  for  the  three  constituencies  of  the  critical 
dialogue  required  to  finally  address  such  issues  raised  at  the  workshop. 

2  Actions  in  1990 

Late  in  1989,  a  different  approach  was  developed  to  continue  with  the  thrust  of  the  original 
workshop.  This  approach  would  avoid  the  constraint  that  resulted  from  the  broad  scope 
of  the  issues  developed  in  the  initial  workshop.  The  new  approach  of  the  SEI  resulted  in 
a  plan  for  a  continuing  series  of  seminars  for  senior  executives  in  industry  and  the  DoD. 
These  seminars  were  to  expand  the  work  done  In  1988,  yet  develop  results  that  would 
be  more  usable  by  the  DoD.  This  redirection  of  effort  was  an  evolutionary  process  that 
occurred  during  the  course  of  the  year  and  was  the  direct  cause  of  the  supporting 
workshop  that  was  held  in  late  1990. 

Participation  in  the  three  planned  seminars  was  focused  on  senior  executive  levels:  chief 
operating  officers  (associated  with  software  issues)  of  major  defense  industry  firms, 
general  officers  concerned  with  acquisition  and  maintenance  of  software  within  the 
uniformed  services,  and  participants  from  the  top  levels  of  the  Office  of  the  Secretary  of 
Defense  who  had  software  management  as  one  of  their  principal  responsibilities.  As  in 
the  1 988  workshop,  one  of  the  primary  purposes  of  these  seminars  was  to  “demystify" 
the  world  of  software  management  for  these  senior  individuals,  who  had  spent  much  of 
their  professional  careers  managing  hardware  and  now  found  themselves  in  the  midst  of 
major  software  developments,  either  in  the  role  of  procurer  or  developer. 
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Although  this  purpose  subsequently  evolved  into  one  of  clarifying  specific  high-ieverage 
software  issues,  as  will  be  discussed  later,  the  primary  objective  of  sensitization  affected 
all  later  plans  and  the  execution  of  the  series  of  Senior  Executive  Seminars  that  followed. 

The  seminars  were  designed  to  encourage  an  informal  sharing  of  experiences  at  each  of 
the  represented  organizations  so  that  participants  would  realize  that  all  had  experienced 
“dismal  failures”  and  "shining  successes.”  Participants  then  attempted  to  identify  the 
underlying  causes  for  the  good  and  the  bad  performances.  Three  separate  seminars 
were  held:  (1)  January  25-26, 1990,  at  Duke  University  in  North  Carolina  for  east  coast 
industry  executives,  (2)  May  9-10, 1990,  in  Scottsdale,  Arizona  for  west  coast  industry 
executives,  and  (3)  September  5-6, 1990,  at  Duke  University  in  North  Carolina  for  DoD 
senior  executives.  Following  these  meetings,  a  workshop  was  conducted  at  the  SEI 
(November  27-28,  1990)  to  address  the  high-leverage  aspects  of  the  most  common 
software  issues  identified  in  the  previous  seminars.  Finally,  a  joint  seminar  was  held  in 
Reston,  Virginia  (December  6-7, 1990),  to  address  the  results  of  the  previous  seminars 
and  the  outcome  of  the  November  workshop. 

The  concept  of  these  efforts  was  that  DoO  concerns  associated  with  the  development  of 
software  would  be  solicited  from  the  DoD  and  relayed  by  the  SEI  to  the  industry 
participants  in  the  initial  two  seminars,  and  the  industry  concerns  about  software 
development  would  be  developed  in  these  two  meetings.  The  SEI  would  then  convey 
the  industry  concerns  to  the  DoD  in  the  third  meeting.  These  meetings  were  informal  in 
nature,  with  no  formal  presentations,  and  aided  by  a  peer  facilitator  to  keep  the 
discussions  flowing  and  focused.  The  workshop  was  designed  to  provide  further 
clarification  on  the  issues  that  were  raised  in  the  fimt  three  seminars,  and  the  results  of  that 
workshop  were  aimed  for  presentation  at  the  fina^  (joint)  seminar  held  in  December. 

The  participants  described  the  meetings  as  being  very  worthwhile  and  suggested  that 
future  meetings  would  provide  a  forum  for  individuals  to  meet  and  discuss  the  formulation 
of  policies  for  acquisition  of  major  software  systems. 


2.1  Seminar  Intent 

The  original  intent  of  the  seminars  was  to  take  the  mystery  out  of  software  programs  from 
a  management  point  of  view  by  acquainting  the  senior  managers  with  some  of  the 
concerns  of  software  people  and  by  showing,  through  shared  experiences,  that  software 
programs  could  be  managed  at  senior  levels  in  virtually  the  same  manner  as  hardware 
programs. 

An  additional  intent  was  to  help  address  the  concern  stated  by  some  OoD 
representatives  that  senior  industry  leaders  were  not  sufficiently  involved  in  their  software 
programs  to  ensure  success.  Software  content  has  grown  to  the  point  that  it  often  costs 
more  than  the  hardware  portion  of  large  system  development  contracts.  A  heightened 
awareness  of  the  significant  software  content  in  virtually  all  major  DoD  procurements  might 
result  in  greater  involvement  at  senior  management  levels  and,  therefore,  in  better 
performance  on  software  contract  obligations. 
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it  was  anticipated  that  by  conducting  the  seminars,  the  SEi  couid  promote  more  effective 
deveiopment  of  software-criticai  defense  systems  on  time  and  within  budget.  As  noted 
eariier.  the  seminars  were  conducted  in  an  informal  environment  in  which  participants  were 
encouraged  to  share  their  experiences  managing  software  programs  and  to  discuss  DoD 
policy  issues  that  may  help  or  hinder  software  development  and  delivery.  The  SEI 
seminars  drew  out  the  views  of  the  participants  on  constructive  actions  that  the  DoD 
policymakers  could  take  to  improve  the  deveiopment  process  and  software  acquisition 
poiicies.  The  SEi  then  provided  the  mechanism  to  reiay  these  issues  and  suggested 
actions  to  the  DoD  poiicymakers  in  the  third  seminar. 


2.2  Accomplishments  1990 

The  seminars  were  viewed  as  being  very  valuable — so  much  so  that,  after  the  third 
seminar  and  at  the  suggestion  of  the  participants,  a  fourth  meeting  was  scheduled  that 
was  a  joint  DoD/industry  seminar  where  issues  and  views  could  be  discussed  directly 
between  the  DoD  and  industry  representatives  under  the  auspices  of  the  SEI.  A 
synopsis  of  the  key  points  that  came  out  of  the  first  three  meetings  is  in  Appendix  A.  A 
weighted  list  of  these  points  as  viewed  by  the  participants  at  the  three  seminars  is  in 
Appendix  B.  A  listing  of  the  attendees  at  each  of  the  first  three  seminars  is  in  Appendix 
C. 

Appendix  A  provides  insight  into  the  issues  concerning  management  from  both  the 
industry  and  DoD  perspectives.  One  of  the  most  striking  facts  is  that  these  issues  are 
quite  similar  across  the  spectrum  of  participants,  as  shown  in  Appendix  B.  The 
differences,  if  any.  lie  mainly  in  the  approach  to  resolving  those  issues.  Although  the 
perspectives  were  somewhat  different,  often  the  suggested  solutions  were  very  similar. 
These  facts  lead  to  the  conclusion  that  there  is  considerably  more  common  ground  than 
might  be  expected  among  the  major  constituent  groups  for  arriving  at  joint  soiutions  to  the 
issues  — providing  a  mechanism  can  be  found  for  DoD  and  industry  executives  to  work 
together. 

it  was  recognized  that  much  thought  and  effort  had  been  previously  spent  in  trying  to 
resolve  most  of  the  issues  that  were  discussed  at  the  seminar;  however,  it  was  apF>arent 
that  much  of  the  effort  had  been  fragmented,  with  each  organization  going  its  own  way  to 
find  a  solution,  it  was  feit  that  a  coordinated  effort  among  the  various  Services  of  DoD, 
the  various  industry  associations,  and  various  industry  companies  could  arrive  at 
workable — and  efficient — solutions  to  these  issues.  Several  approaches  were 
discussed,  but  no  final  approach  was  selected. 

As  noted  in  Appendix  A,  the  issues  upon  which  there  was  consensus  were: 

•  Requirements  definition. 

>  Realistic  expectations  of  cost,  schedule,  and  system  performance. 

•  Government  program  management  capability  and  continuity. 

•  Software  evoiution  on  a  planned  basis. 

•  Use  of  commercial  off-the-shelf  (COTS)  software. 
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•  Software-related  metrics. 

•  Procurement  methods  such  as  cost  plus  award  fee  contracts. 

•  Post-delivery  performance  incentives  on  software. 

•  Support  and  guidance  for  universities. 

•  Software  work  breakdown  structures. 

•  Continued  investment  in  productivity  improvement. 

•  Shared  responsibility  between  industry  and  government  for  the  “problem”  and 
the  "solution.” 

Some  of  these  issues  are  normally  worked  on  at  lower  levels  within  various  organizations, 
but  ..iany  are  items  that  can  only  be  resolved  by  senior  management.  It  was  felt  that 
these  seminars  had  created  an  awareness  in  the  minds  of  the  attendees  of  the  criticality  of 
the  issues  that  would  promote  timely,  lasting  solutions. 

Of  particular  interest  to  the  attendees  were  the  handouts  that  provided  specifics  that  they 
could  take  from  the  meetings  and  use  in  their  offices.  One  such  item,  Appendix  0,  was 
the  table  of  software  development  difficulties.  This  chart  laid  out  the  “roof  causes, 
common  problems,  and  the  symptoms  of  poor  software  development  performance.  It  was 
identified  that  too  often,  all  a  manager  sees  are  the  symptoms  and  problems — never 
arriving  at  the  root  causes  for  these.  With  this  chart,  managers  can  identify  the  root 
causes  and  solve  the  problems  in  their  organizations  as  opposed  to  treating  the  same 
symptoms  over  and  over. 

Appendix  E  lists  five  major  risk  areas  for  software  projects.  Understanding  that  these  are 
the  areas  of  risk  most  likely  to  occur  in  a  program  helps  managers  to  ask  specific 
questions  to  determine  if  the  risk  applies  to  their  project.  Moreover,  if  the  risk  does  apply, 
such  knowledge  will  ensure  that  appropriate  steps  are  taken  to  mitigate  or  eliminate  the 
risk.  While  these  risks  apply  to  hardware  programs  also,  the  second  page  of  Appendix  E 
articulates  some  specific  software  risks  that  fall  out  of  the  major  risk  areas. 

Appendix  F  provides  a  list  of  suggested  questions  for  the  senior  executive  to  ask  a 
software  manager  to  determine  the  competence  of  the  software  department  to  handle 
major  programs.  Appendix  G  provides  a  list  of  questions  to  ask  program  managers  to 
determine  the  status  or  “health”  of  individual  programs  under  development.  These  lists 
provide  points  of  departure  for  an  organization  to  raise  the  visibility  of  software  issues 
within  systems  development  and  maintain  adequate  effort  to  ensure  correct  software 
development. 


2.3  Seminar  Conclusions  1990 

The  conclusions  discussed  herein  may  repeat  some  of  the  points  noted  earlier;  however, 
it  is  felt  that  repetition  is  warranted  to  present  all  of  the  significant  findings  in  one  section  of 
this  special  report. 
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First,  it  is  worth  noting  that  the  concerns  and  issues  expressed  in  the  various  seminars 
were  very  similar  and  many  of  the  suggested  solutions  also  were  similar.  This  fact 
provides  a  basis  for  the  expectation  that  usable,  lasting  solutions  can  be  found.  The 
following  discussions  summarize  the  key  software  issues  derived  from  the  1 990  Senior 
Executive  Seminar  Series. 


2.4  Establishing  Realistic  Requirements 

All  participants  agreed  that  this  issue  was  one  of  the  basic  causes  for  contractor 
performance  not  measuring  up  to  government  expectations  and,  in  many  cases  for  not 
complying  with  contract  requirements  in  terms  of  cost  and  schedule.  The  source  of  the 
problem  stems  from  naive  planning  and,  occasionally,  political  overrides.  The  government 
seminar  participants  felt  that  an  adequate  review  of  the  draft  request  for  proposal  (RFP) 
should  provide  the  means  to  correct  any  lack  of  realism  that  it  may  contain.  Contractor 
participants  felt  the  government  did  not  want  nor  would  they  accept  comments  aimed  at 
realism  and  as  long  as  at  least  one  contractor  responded  back  with  the  “party  line.”  no 
changes  would  be  made.  Suggested  solutions  included: 

•  Contractually  augment  the  procurement  team  with  sources  of  expertise — people  who 
have  done  similar  work. 

•  Open  up  the  interactions  between  government  and  industry  prior  to,  during,  and  after 
preparation  of  the  RFP — don’t  allow  inputs  for  more  realistic  objectives  to  go 
unheeded  or  the  comments  to  be  used  against  the  contractor  in  subsequent 
competitions. 

•  Develop  better— realistic— measures  of  performance  based  on  past  history, 
meaningful  metrics,  and  better  estimating  models,  and  increase  emphasis  on  past 
performance  and  credibility  in  source  selection. 

2.5  Defining  Requirements 

It  was  noted  ‘1hat  software  systems  seldom  fail  to  comply  with  the  contract  but  almost 
never  meet  what  they  are  supposed  to  do.”  This  is  probably  an  overstatement  but  it 
does  show  the  frame  of  mind  of  the  participants.  The  concern  stems  from  the  fact  that 
software  requirements  are  generally  not  defined  until  late  in  system  development.  The 
software  is  usually  expected  to  make  up  for  deficiencies  in  the  selected  hardware  suite 
and,  therefore,  requirements  continue  to  evolve  throughout  system  development.  Further, 
and  perhaps  most  critical,  the  users  are  isolated  from  the  system  developer  in  fear  of 
“creeping  enhancement  growth”  of  the  system.  Suggested  solutions  included: 

•  Ensure  that  the  Defense  Acquisition  Board  (DAB)  process  has  full  visibility  into 
planned  programs,  including  a  software  risk  assessment. 

•  Provide  for  user  involvement  at  major  reviews  and  throughout  the  development  cycle 
to  ensure  a  "shared  vision”  of  the  product. 
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•  Provide  for  simulation  and  prototyping  to  improve  visibility  into  the  system 
capabilities. 

•  Take  advantage  of  software's  inherent  easy  modification  and  evolution  capability  by 
defining  block  upgrades  of  the  system  in  a  preplanned  product  improvement 
approach. 

•  Ensure  that  the  operations  concept  of  a  system  is  included  as  part  of  the  RFP. 

2.6  Software  Acquisition  Process 

Current  acquisition  practices  are  based  on  hardware  models  and  do  not  lend  themselves 
to  software  procurements.  There  is  a  need  to  recognize  early  in  a  system  development 
what  the  degree  of  software  content  will  be  in  the  system,  using  systems  engineers  who 
are  versed  in  software  and  hardware  capabilities.  Early  recognition  of  the  degree  of  cost 
and  scheduling  risk  inherent  in  the  software  portion  of  the  system  is  critical  to  realistic 
acquisition  plans.  An  understanding  of  overall  life-cycle  implications  is  very  important. 
Suggested  solutions  included: 

•  Use  incremental  acquisition — longer  term  contracts  that  allow  incremental  builds  and 
delivery  of  software  systems. 

•  Use  cost-type  contracts,  preferably  cost  plus  award  fee,  for  software  development 
and,  if  appropriate,  firm  fixed  price  contracts  for  the  hardware  portion  of  the  system 
(some  government  people  felt  these  contracts  could  go  to  separate  contractors,  while 
the  industry  people  generally  felt  this  would  be  inefficient  and  result  in  much  finger 
pointing  and  litigation). 

•  Establish  explicit  software-related  criteria  for  award  fee  determination,  possibly  even 
including  post-delivery  awards  on  performance;  and  recognize  the  peculiarities  of 
software  versus  hardware  in  the  scheduling  of  major  milestones  such  as  preliminaiy 
design  review,  critical  design  review,  etc. 

2.7  Metrics 

This  issue  resulted  in  heated  discussion.  Some  participants  felt  that  good  metrics  were 
available  but  were  not  being  used  properly,  while  others  felt  current  metrics  were 
useless.  It  was  finally  agreed  that  something  must  be  done  and  "metrics"  would  best  be 
served  if  there  were  a  joint  DoD/industry  effort.  Inadequate  and  inconsistent  data  exist  for 
predicting  and  assessing  software  cost,  schedule,  and  quality.  The  suggested  solution 
involved  a  joint  DoD/industry  working  group  to  identify  minimal  system  management 
needs  and  a  metric  set  that  would  allow  procurement  and  development  people  to  know 
where  they  are  in  the  reai  status  of  software  programs.  This  working  group  should  be 
under  the  auspices  of  the  SEI. 
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2.8  Work  Breakdown  Structure  (WBS) 

Current  WBS  direction  allows  a  single  block  for  the  software  portion  of  total  system 
development.  It  was  felt  that  this  did  not  give  proper  emphasis  nor  visibility  to  the 
magnitude  of  the  software  effort.  A  detailed  software  WBS  is  required  to  record  actual 
person-hours  for  software  development.  Some  of  the  ongoing  efforts  in  this  area  were 
recognized  but  participants  felt  these  would  be  *100  little,  too  late.”  The  suggested 
solution  was  a  joint  DoD/Industry  working  group  to  work  closely  with  the  metrics  effort  to 
define  a  WBS  that  would  support  the  collection  of  data  needed  to  provide  meaningful 
management  decisions  and  to  support  the  identified  metrics.  The  WBS  should  take  the 
development  of  software  through  the  various  steps  from  inception  to  final  test  with  the 
hardware  suite. 


2.9  Simulation  and  Prototyping 

Most  of  the  discussion  on  this  issue  centered  on  the  cost  involved  in  a  formal  simulation 
and  prototyping  program  and  whether  or  not  it  would  save  money  in  the  long  run.  Almost 
all  of  the  participants  agreed  that  such  a  program  went  a  long  way  toward  reducing  risk  in 
software  development;  however,  they  were  unanimous  in  saying  that  money  is  seldom,  if 
ever,  forecast  or  budgeted  on  the  government  side  for  this  purpose.  Therefore,  the 
contractors  do  not  propose  the  approach  because  it  would  make  them  noncompetitive 
from  a  cost  point  of  view.  Suggested  solutions  induded: 

•  Incorporate  requirements  for  simulation  and  prototyping  in  the  RFPs,  where 
appropriate. 

•  Include  cost  and  schedule  implications  in  the  budgeting  process. 

•  Formalize  the  prototyping  process;  and  increase  government  and  industry  expertise 
to  institutionalize  the  requirement. 


2.10  Software  Productivity 

This  is<;ue  received  more  discussion  than  any  other  subject  because  it  was  felt  to  be  so 
necessary,  yet  so  hard  to  define.  The  productivity  of  individual,  acceptable  coders  may 
vary  by  factors  of  30  to  50  times  when  efficiency  of  the  produced  code  is  considered. 
Also  the  capital  investment  required  to  improve  the  software  development  environment 
may  be  very  large.  The  state  of  the  art  is  changing  so  rapidly  that  initial  investments  may 
be  wasted.  Suggested  solutions  included: 

•  Support  and  expand  industry/govemment  process  improvement  programs. 

•  Modify  the  SEI  assessment  questionnaire  to  include  more  emphasis  on  productivity. 

•  Develop  a  strategy  that  enhances  development  of  software  support  environments. 

•  Use  the  Army  Materiel  Command  process  Improvement  program  as  a  model  for 
estimating  workload  and  required  resources. 
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2.11  Commerclal-Off-the<Shelf  (COTS)  Software 


Industry  is  very  interested  in  using  COTS  software  to  obtain  competitive  advantage. 
However,  the  legal  and  support  limitations  do  not  always  make  it  cost-effective  nor 
appropriate  for  OoD  programs.  The  barriers  to  using  COTS  need  to  be  identified  and 
draft  language  is  needed  for  DoD  regulations  that  will  address  these  barriers  and  make 
them  less  onerous.  Suggested  solutions  include. 

•  Specify  where  and  how  COTS  is  to  be  applied  in  the  RFP. 

•  Review  appropriate  regulations  to  insert  COTS  requirements. 

•  Work  with  commercial  software  vendors  to  encourage  their  permitting  use  of  their 
software,  including  a  reasonable  set  of  DoD  acceptable  documentation  for  COTS 
use. 

•  Develop  regulations  that  deal  equitably  with  the  liabilities  associated  with  COTS  use 
from  the  viewpoint  of  the  government,  the  prime  contractor,  the  subcontractor,  and  the 
COTS  software  vendor. 


2.12  Separate  Independent  Verification  and  Validation  (IV&V) 
Contractor 

This  issue  was  brought  up  by  some  of  the  government  participants.  They  felt  that 
separate  IV&V  contractors  were  neither  cost-effective  nor  resource-effective  and  that  the 
development  contractor  should  perform  this  function  as  a  matter  of  routine  and  good 
business  practice.  Quality  must  be  “engineered  into  the  system  not  forced  in  by  threat  of 
an  IV&V  policeman.”  Suggested  solutions  include: 

«  Moving  from  separate  IV&V  to  an  internal  audit  function,  followed  by  moving  from  an 
audit  function  to  process  and  related  metrics. 

«  Application  of  total  quality  management  (TQM)  techniques  would  be  most  beneficial. 


2.13  Support  of  Universities 

Although  there  were  no  suggested  solutions,  the  participants  were  unanimous  in 
expressing  the  need  for  much  closer  cooperation  with  universities.  This  cooperation 
would  include  such  items  as  increased  involvement  by  industry  in  shaping  the  curriculum 
for  software  professionals.  It  was  felt  that  universities  are  not  turning  out  graduates  who 
are  useful  in  the  defense  industry  without  a  great  deal  of  training  by  industry  or  the  DoD. 
The  Ada  culture  should  be  promoted  at  the  university  level.  While  there  was  consensus 
on  the  need  for  more  industry  Involvement  with  academia,  the  discussed  solutions  varied, 
because  each  organization’s  involvement  tends  to  reflect  the  personal  interest  of  the  most 
senior  management. 

Appendix  A  is  a  more  complete  listing  of  the  issues,  concerns,  and  suggested  solutions. 
Additionally  there  were  a  number  of  actions  or  studies  suggested  to  be  undertaken  by  the 
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SEI  with  support  from  the  DoD/industry  organizations.  These  are  also  itemized  in 
Appendix  A.  These  suggestions  are  under  review  by  the  SEI  for  appropriateness  and 
availability  of  resources. 


CMU/SEI-92-SR-1 


9 


3  Transition 


The  1990  sessions  focused  senior  management  attention  on  major  software  issues  that 
are  long  standing  and  have  not  been  resolved.  They  provided  the  participants  with  a 
fuller  appreciation  of  the  complexity  of  the  issues  and  the  time  required  for  solutions. 
Support  was  offered  by  the  participants  to  drive  toward  acceptable  solutions.  A  strong 
suggestion  was  made  and  seconded  by  all  participants  that  the  forum  and  mechanism 
suggested  by  the  SEI  should  be  pursued.  This  included  the  general  agreement  that  the 
SEI  should  continue  with  annual  or  semiannual  meetings,  with  the  same  set  of 
participants,  with  the  goals  of  monitoring  progress  toward  issue  solutions,  identifiying  new 
issues,  and  assigning  responsibility  for  action  items. 


3.1  Recommendation 

On  January  21 , 1991 ,  the  Director  of  the  SEI  forwarded  a  letter  to  the  Deputy  Secretary 
of  Defense  explaining  the  software  issues  that  the  Senior  Executive  Seminars  of  1 990 
had  identified.  The  letter  also  identified  a  proposed  forum  and  structure  of  a  mechanism  to 
continue  to  identify  and  address  such  issues.  The  momentous  events  of  Operation 
Desert  Storm  and  the  reorganization  of  the  Office  of  the  Secretary  of  Defense  (OSD)  led 
to  the  action  of  execution  of  this  forum  and  mechanism  to  be  placed  in  abeyance  awaiting 
clarification  from  OSD. 

3.2  Redirection  of  Effort 

On  February  13, 1991,  the  Director  of  the  SEI  forwarded  letters  to  the  Senior  Executive 
Seminar  participants  that  explained  the  delay  in  the  institution  of  the  proposed  forum  and 
mechanism.  This  letter  also  marked  the  beginning  of  clarification  being  made  available  from 
OSD  of  where  the  focus  would  reside  concerning  software  issues.  In  May  1991,  the 
responding  letter  to  the  letter  sent  to  Deputy  Secretary  Atwood  was  received  at  the  SEI. 
In  this  letter.  Dr.  Hertzfeld  (then  DDR&E)  stated  that  elements  within  OSD  had  been 
reviewing  the  issues  raised  by  the  SEI  letter  and  various  OSD  mechanisms  were  being, 
studied  that  could  best  accomplish  the  goals  outlined  in  the  letter.  With  this  response,  it 
became  apparent  that  the  OSD  was  pursuing  steps  that  would  help  address  the  basic 
goals  of  the  Senior  Executive  Seminars  of  1990. 

On  June  1,  1991,  the  SEI  established  a  presence  in  Washington,  D.C.,  with  the  direct 
charge  to  assist  in  the  completion  and  production  of  the  DoD  Software  Technology 
Strategy  (SWTS).  This  same  presence  was  established  as  the  Secretariat  of  the  newly 
established  DDR&E  Software  Action  Plan  (SWAP)  Working  Group. 
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4  Software  Action  Plan  (SWAP) 


On  June  4,  1991,  Mr.  Charles  E.  Adolph,  the  acting  DDR&E,  signed  a  memorandum 
addressed  to  Assistant  Secretary  of  Defense  (Command,  Control,  Communications,  and 
Intelligence,)  and  the  Service  Acquisition  Executives,  initiating  the  DDR&E  Software 
Action  Plan  (SWAP).  This  memorandum  also  instituted  a  working  group  charged  “to 
develop  and  lead  the  Implementation  of  an  integrated  technology  and  management  plan  to 
ensure  more  cost-effective  software,  software  support,  weapons  systems,  and  related 
test  equipment  systems  within  the  DDR&E  purview.” 

4.1  SWAP  Candidate  Actions 

In  building  a  candidate  actions  list  to  be  addressed  in  the  SWAP-Working  Group,  focus 
was  placed  on  actions  with  high  leverage  on  software  development  and  acquisition 
throughout  the  DoD.  As  a  critical  input  to  the  creation  of  this  candidate  actions  list,  the 
recommended  actions  from  the  1990  Senior  Executive  Seminar  Series  were  addressed. 
Appendix  H  is  the  initial  list  of  the  accepted  Candidate  Actions  that  the  SWAP-Working 
Group  has  begun  to  review. 


4.2  Synergy  Between  the  SWAP  and  the  Senior  Executive  Seminar 
Participants 

As  an  example  of  the  Impact  that  the  Senior  Executive  Seminar  Series  has  had  in  the 
SWAP  Working  Group  candidate  action  number  003  software  cost  reporting  standards, 
which  represents  the  first  example  of  close  synergy  between  the  work  done  under  the 
auspices  of  the  SWAP  and  the  industry  representatives  who  had  participated  in  the  1990 
Senior  Executive  Seminars.  In  searching  for  answers  posed  by  senior  OSD  officials 
concerning  the  impact  of  instantiating  software  cost  reporting  standards  in  the  software 
industry,  the  participants  in  the  1990  Senior  Executive  Seminars  were  polled  by  the 
director  of  the  SEI  to  request  knowledgeable  people  who  could  participate  in  a  sub-work 
group  to  discuss  this  issue  and  develop  responses  to  the  OSD  questions.  This  work 
group  met  during  the  1991  SEI  Software  Engineering  Symposium  on  August  27, 1991. 
The  result’s  of  the  sub-work  group’s  deliberations  were  provided  to  the  SWAP-Working 
Group  and  then  forwarded  to  the  cognizant  OSD  official.  These  responses  were 
instrumental  in  the  overall  decision  by  OSD  concerning  the  institution  of  such  standards. 
Such  synergy  continues  on  an  issue-by-issue  basis  and  is  based  on  OSD  concerns  and 
funds  available. 


5  The  Future 

The  originally  proposed  mechanism  for  the  critical  interchange  between  senior  executives 
in  industry,  the  DoD,  and  academia  is  directly  related  to  the  transition  element  of  the  SEI 
charter.  With  the  establishment  of  the  DDR&E  SWAP  Working  Group,  the  OSD  segment 
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of  the  mechanism  is  being  developed.  Current  re-focusing  of  responsibilities  within  OSD, 
associated  with  software  issue  identification  and  resolution,  will  provide  a  clearer  process 
which  can  then  act  as  the  basic  building  block  for  the  forum  and  mechanism  found  in 
paragraph  1 .3.2.  The  SEi  remains  committed  to  supporting  a  realistic  mechanism  that 
serves  the  purpose  of  opening  the  critical  dialogue  between  the  three  constituent  groups. 
The  SEI,  as  a  federally  funded  research  and  development  center  charged  with  software- 
related  issues,  is  superbly  placed  to  provide  the  synergistic  element  that  will  assist  in 
addressing  these  critical  software  issues. 
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